NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/644

Internet Message Format | 1996-08-05 | 8.0 KB

Path: nntp.teleport.com!sschaem
From: [e-mail] (Stephan Schaem)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: PPC compilers
Date: 9 Jan 1996 23:08:33 GMT
Organization: Teleport - Portland's Public Access [phone]
Message-ID: <4cushh$[e-mail]>
References: <[e-mail]> <4b77tq$[e-mail]> <MQAQx*[e-mail]> <4bqhnf$[e-mail]> <[e-mail]> <4c9i2l$[e-mail]> <4cf0ep$233@ra.i
   <4ck47h$[e-mail]> <[e-mail]> <4com6v$[e-mail]> <[e-mail]> <4crfb9$[e-mail]> <[e-mail]>
NNTP-Posting-Host: kelly.teleport.com
X-Newsreader: TIN [version 1.2 PL2]

Jason S Birch ([e-mail]) wrote:
: [e-mail] (Stephan Schaem) writes:
: >Jason S Birch ([e-mail]) wrote:
: >: Again: *If* he's trying to create a data type with certain
: >: implementation-dependent size-requirements (such as in the bltcon0
: >: case, assuming no headers to give us one) *then*, at that point in
: >: time, he has to know the size of the type in order to define it
: >: correctly. He stated that earlier - check what I've underlined.

: > He said he would create a structure... not a new type.

: You're saying a new structure *isn't* a new type?

 I'm saying decalring element of a structure... if you make an element
 public & declar it a ulong... you better keep it a ulong from then on.

: > Now, tell me how he can forget that chipregs->bltcon0 is
: > of type UWORD when he will declar *b and use *b (I guess you
: > could forget what type are your variable, but personaly think its
: > not to wise)

: typedef uword bltcon0_t;
: ...
: struct chipregs_t {
:     ...
:     bltcon0_t    bltcon0;
:     ...
: };

: struct chipregs_t    chipregs;
: bltcon0_t            *b;

: Now he can safely use *b wherever a bltcon0_t is required, and given
: sufficient support functions, never needs to know that it's a uword -
: all he has to keep in mind are what values a bltcon0_t is allowed to
: take.

 Ok, I agree, with support function this take a all new dimention.

: > I'm sorry again , I dont see how you can program not knowing
: > the type of your variable when you use them? Is it a pointer to a
: > string C string? a pointer to a P String?

: Again, you're misunderstanding. If you have a type blah, and a
: function takes a variable of type blah *, then by all means create a
: variable of type blah (or blah *) and pass it's address (or the
: variable itself) to the function. You do *not*, however, need to know
: if blah is really, say, a 32-bit integer. With assembler, you do.

 In assembler you need to know its of type long... long just
 happen to be a 32bit integer. you will declare you variable in asm
 of type long, and use it has a long... in C you will declare of
 the variable of type blah and use it has type blah.

 Now you foget your variable if of type blah and you will probably write
 something the compiler will chock on convert for you, if possible.

 In asm you forget your variable is of type word and you use it to
 store a long result... you are dead, I never said assembler to type
 chacking. I just said in asm or C you need to know your variable type.

: > Should I mask the variable
: > before I shift? etc...

: If you use bitfields, you don't even have to care about masking and
: shifting:

: typedef struct {
:   int foo : 2;
:   int bar : 4;
:   int bob : 10;
: } fred_t;

 For me here I see a structure with 3 type.

 foo, bar, bob need to be defined somehow to the programmer.

 is bob an integer value holding a range of 0 to 1024 for luminance
 is foo really a bolean value and range from true to false?
 ....

 But what I said with bit masking is that for example >> replace the
 incoming bit with zero but you cant assume what those are.

: Structures *are* types.

 element of structure are not, unless you can

 structure.element  variable;

: > move.type    (a0),(a1) ... so what if type read .word or .chipreg

: The "so what" is that you *need* to know if it really is a type .word,
: or .byte, and can't simply use it as type .chipreg. Oh, and you have
: to repeatedly say .word (or whatever) almost every time you use it.

 In C or ASM I know my variable type... In asm I write it down, in C
 I dont. The point is I know my variable type, that mean I know the type
 range. (bolean, short integer, long integer, real, etc..)

 If you write

 vector    a,b,c;

 ...

 c = a*b;

 etc..

 without knowing that vector is actually a strcture you are just unwise.
 You HAVE TOO in C or asm know what are your variable type, and know what
 the type is.

: > In asm you are forced to write what your thinking in all its detail,
: > this mean forced to know your variable type. Something you should do
: > even in C.

: Not if you want portable code, you shouldn't, and with sufficient
: support functions, you needn't.

 Soon we will talk about c++ vs asm... support function where never in the
 picture till now. but what I'm saying is, you dont forget your variable
 type after you declar them, its just not possible... and if you
 really do not know the type definition you will not use them directly,
 but use function

 In asm the chip offer basic function on type like  WORD  and LONG, but
 you are limited to those only at the chip level. Speaking of
 portable code in asm is silly, but if you want to write high level code
 you will create typed objects & taged functions + marcos...

 The thing I agree is that you cannot typdef a type in asm (Its possible
 just not ofered).

: >: The question is not about whether you need to know if a variable is a
: >: float or a long, since they are "abstract" types (and can be different
: >: sizes on different machines). The question is whether you need to know
: >: how many bits are in each, and what each bit means. In assembler, you
: >: do need to know the former, and occasionally the latter.

: > When you program in C... on what basis do you select your variable type?
: > Do you limit yourself to int/float? for all integer work you use int,
: > and real you use float?

: Of course not. If I need a lot of precision, I use double. If I prefer
: speed and it doesn't need to be so accurate, I use float. If it
: doesn't need to be floating point at all, I'll use an ordinal type. If
: I don't want to have to care how big it's going to be on a particular
: implementation, I'll go with long or perhaps "natural", where natural
: can be typedef'd appropriately when sizeof(word) and sizeof(long) are
: known. You are quite welcome, as I've said, to use the knowledge that
: ANSI guarantees. If you want to be safe, however, you should not use
: information that your particular implementation defines.

: > In C or asm I choose type according the the min range they hold.
: > I cant imagine choosing a type for my operation without knowing the
: > type range.

: You can't know the type range beforehand for any possible
: implementation. C does not guarantee it. You can use sizeof at compile
: time, however.

: >: > ANSI define very well the minimum size of its type.

: >: It does *not* define that ushort is the same as two bytes, which is
: >: what you are claiming above as being equivalent. It only guarantees
: >: that char <= short <= long.

: > It define that ushort can hold value from 0 to 65535... this is what I
: > claim. ANSI C do define min range for the basic types, it would be
: > unthinkable otherwise.

: It does *not* define that ushort can hold values from 0 to 65535.
: Check it. There are machines with other than multiples of 8 bit word
: sizes, you know.

: > Stephan

: --
: Jason S Birch                        ,-_|\ email: [e-mail]
: Department of Computer Science      /     \ Tel (work): [phone]
: The University of Western Australia *_.-._/ Fax (work): [phone]
: Nedlands  W. Australia  6907             v  Tel (home): [phone]

--
[e-mail]  Public Access User -- Not affiliated with Teleport
Public Access UNIX and Internet at [phone] (2400-28800, N81)